| Windows XP Bootvis Tool |
The underlying causes of a delay in S3 resume performance are often not readily apparent in Bootvis. While Bootvis can be helpful in collecting and analyzing resume performance data, it is often not possible to draw conclusions about which driver may be impeding the resume process. However, Bootvis can help system designers in understanding where to start investigating resume performance issues. Gaining an understanding of common S3 behaviors and resume issues can help.
Windows XP introduced many design changes and code optimizations to greatly improve resume from standby performance. Resume times of less than 2 seconds are easily achievable on Windows XP, assuming the system's BIOS and installed drivers were also designed to perform well in their resume paths. However, the S3 resume code path is still vulnerable to page faults. Windows employs a virtual memory subsystem that uses demand-based paging. During resume, any software executing, including Windows XP itself or driver code for an add-in device, may reference pages that are not currently resident in system memory. The page fault that results cannot be satisfied until the hard disk completes its spin up and can retrieve data from the disk. This is particularly evident on the first standby/resume cycle after the system has been booted. Typically, once the standby/resume code paths have been run at least once, there is a greater likelihood that those code pages needed on the resume path may be resident in memory on the next resume cycle. However, normal system use can cause these pages to be swapped out to disk. This problem is particularly likely on systems with less available memory, e.g. UMA systems, or when many programs are run simultaneously, etc.
Bootvis' graphical display of resume data and its time aligned child windows of system resume activity make it easy to identify an S3 resume trace that was blocked due to pending disk I/O. Consider the following example.
The Bootvis resume summary window below was taken on a system with otherwise typically good standby resume performance. The data below reflects the performance on the first standby/resume cycle after the system was cold booted. As reflected by the resume summary data, the system's BIOS handoff time is quite acceptable at 38ms; however, the total system resume time is unacceptable at 5.77s, and bootvis attributes 5.28s of the total resume time to driver initialization.
Looking at Bootvis' resume activity windows makes the breakdown of where time is spent on the resume path even more evident. In the figure below, the long delay in driver initialization is obvious.
Examining the driver delay window, it would appear as if the driver serenum.sys is gating the S3 resume process on the completion of its S0 IRP.
However, the Disk I/O window shows disk activity at almost the same point in time that the serenum.sys S0 IRP completes, and from that point on resume progress continues and resume completes shortly thereafter.
Examining the details of the disk activity can be useful in understanding the resume process for a given trace. To view the details of disk I/O, follow these steps:
Looking at the Disk I/O summary table for the resume trace in our example, the system access to the page file is readily apparent.
